home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 4770 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  7.5 KB
  1. Path: grafix.xs4all.nl!john.hendrikx
  2. Date: Sun, 03 Mar 96 00:06:34 GMT+1
  3. Newsgroups: comp.sys.amiga.programmer
  4. Distribution: world
  5. Subject: Re: Amiga doesn`t need Pl
  6. MIME-Version: 1.0
  7. Content-Type: text/plain; charset=iso-8859-1
  8. Content-Transfer-Encoding: 8bit
  9. From: john.hendrikx@grafix.xs4all.nl (John Hendrikx)
  10. Message-ID: <john.hendrikx.4iy3@grafix.xs4all.nl>
  11. Organization: Private
  12.  
  13. In a message of 25 Feb 96 Juergen "rally" Fischer wrote to All:
  14.  
  15.  JrF> todays 1230 or 1240 should be able to do same (wasn't doom busy waiting
  16.  JrF> for vblank bit? I think so!)
  17.  
  18. As DOOM was tripple-buffered I don't see why, unless it would run faster than
  19. the display update rate.
  20.  
  21.  >>  JrF> You rely on _programming crap_ in combination with low cpu. No, a
  22.  >> game which is unplayable because it uses a fuzzy 2x2 160x120 display (or
  23.  >> less!) and jerks like hell is CRAP.
  24.  JrF> fuzzy 2x2 due to low cpu, jerk due to low cpu. not AGA.
  25.  
  26. So speed would remain the same if AGA had been Chunky?  Maybe it makes little
  27. difference on mega-big-CPU (as long as you stick with LoRes that is) but it
  28. will make quite a difference here.
  29.  
  30.  >>  Blitter assistance: Requires non-interleaved bitmaps, impossible to
  31.  JrF> that's no problem.
  32.  
  33. Not always, it depends on what 'other' stuff you want to do in your game.
  34.  
  35.  >>                      C2P a smaller part of the whole screen
  36.  JrF> that's no problem concering games like doom.
  37.  
  38. Isn't it?
  39.  
  40.  >>                      on factors like CPU, fast-memory, etcetera...
  41.  
  42.  JrF> The disadvantage is that you got to code more, right. no technical
  43.  JrF> argument.
  44.  
  45. Oh sure, just code a bit more, I guess that's why we see so many DOOM clones
  46. which actually USE this kind of stuff, NOT.
  47.  
  48.  >>                      Try to get it to work on Intuition-screen and make
  49.  >>                      your DOOM-clone support multiple window sizes.
  50.  JrF> closescreen. openscreen.
  51.  
  52. Shitty solution.  I suppose the overlayed text should also have to be shrunk
  53. accordingly?  What about the status panel? Just open another screen you say? 
  54. Another 'special' routine as this can't be used on most gfx-cards.
  55.  
  56.  >>       Chunky Copper: Crappy resolution, wastes lots of ChipRAM bandwidth
  57.  JrF> demo only.
  58.  
  59. Most of the stuff I've seen here is 'demo' only.  For example, using 64K for a
  60. single texture and stuff like 256K loop-up tables are quite unrealistic for
  61. real games.
  62.  
  63.  JrF> I already got 1pass. still got 2pass to write, ludde is said to have
  64.  JrF> it done free.
  65.  
  66. Don't forget to ask him what 'new' limitations this 'trick' will introduce.
  67.  
  68.  >> and probably one which uses AKIKO, and of course for each of these
  69.  >> routines a
  70.  JrF> FORGET AKIKO.
  71.  
  72. Oh, I bet there is some 'strange' config which could actually make AKIKO an
  73. advantage (maybe AKIKO + BlitterAssistance or something stupid like that?)
  74.  
  75.  >> version which does 2x1 displays, and versions for 16, 64 and 256 colors.
  76.  >> Maybe also add ChunkyCopper and BlitterScreen C2P?  It looks like we've
  77.  >> gone C2P
  78.  JrF> FORGET COPPER.
  79.  
  80. I did that years ago, when everybody kept begging me to add copper-screens to
  81. TextDemo.
  82.  
  83.  JrF> blitterscreen is only nessesary for fast clones, otherwise use 4pass.
  84.  
  85. Why don't you make a huge IF THEN kind of list of C2P routines, like this:
  86.  
  87.   IF AGA=TRUE AND GFXCARD=FALSE
  88.      IF 040=TRUE
  89.         IF 040=SLOW4000/040
  90.             use CPU 3-pass 32-bit C2P + blitter assistance (or whatever)
  91.         ELSE
  92.             use CPU only C2P
  93.         ENDIF
  94.      ELSE IF 030=TRUE
  95.         IF MHZ=>33
  96.             use 3-pass 32-bit C2P + blitter assistance
  97.         ELSE
  98.             use 2-pass 32-bit C2P + blitter assistance
  99.         ENDIF
  100.      ELSE
  101.         IF FASTRAM=PRESENT
  102.             IF AKIKO=TRUE
  103.                 use AKIKO + blitter assistance
  104.             ELSE
  105.                 use ...
  106.             ENDIF
  107.         ELSE
  108.             IF AKIKO=TRUE
  109.                 use ...
  110.             ELSE
  111.                 use ...
  112.             ENDIF
  113.         ENDIF
  114.      ENDIF
  115.   ELSE IF ECS=TRUE AND GFXCARD=FALSE
  116.      IF ...
  117.         ...
  118.      ELSE
  119.         ...
  120.      ENDIF
  121.   ELSE IF OCS=TRUE AND GFXCARD=FALSE
  122.      IF ...
  123.         ...
  124.      ELSE
  125.         ...
  126.      ENDIF
  127.   ELSE
  128.      IF BUS=ZII
  129.          IF SEGMENTED=FALSE
  130.              IF PICASSO=TRUE
  131.                  ...
  132.              ELSE
  133.                  ...
  134.              ENDIF
  135.          ENDIF
  136.      ELSE
  137.         ...
  138.      ENDIF
  139.   ENDIF
  140.  
  141. and so on, and oh I forgot, the best C2P routine to use also depends on how
  142. much rendering needs to be done (ie, what resolution and how big the screen is)
  143. so take that into account too!
  144.  
  145. And some people claim here that having to take all the gfx-cards on the clones
  146. into account is such a big problem...
  147.  
  148.  >> There is no Amiga with the same power as the P133.  And my 'average' (and
  149.  >> 2 year old $100) VLB Gfx card handles 15 MB/sec easily, more than enough
  150.  >> to do 640x480 in 2 frames.
  151.  
  152.  JrF> If 15mb/sec is more than enough to do 640x480 gfx, 6mb/sec surely are
  153.  JrF> no problem doing 320x160 ;) you contradict yourself :)
  154.  
  155. You claim things not having been done yet.  What was that 20-25 ms figure which
  156. most 040 C2P routines get?
  157.  
  158.  JrF> ok, 10 planes would need a faster cpu. Maybe one of the faster PPCs
  159.  JrF> could do c2-10p in 15mb/sec ? :) If so this would outrule non-paletted
  160.  JrF> 16bit displays (smother shading) and 24bit displays in terms of shding
  161.  JrF> speed (with 10 bit just use 4 for shading, doing shading with just
  162.  
  163. 16 shading levels with just 64 colors?  No thanks.  I'll go for the 15/16-bit
  164. screen with 65536 colors with on average 16 shading levels.  Or maybe I'll just
  165. use some of the more fancy YCrCb modes were Y is the intensity level.
  166.  
  167.  JrF> adding a register, no table-lookup -> more speed. Imagine descent real
  168.  JrF> gouraudshaded :).
  169.  
  170. Why imagine?  There are already games doing that.
  171.  
  172.  >> There is no (good) clone because it requires a 040 + fast Chunky
  173.  >> gfx-card, period.  Caused of course by the fact that 040 + fast Chunky
  174.  >> gfx-card is a rare combination found in the Amiga world.
  175.  
  176.  JrF> "That's why there is no clone, the C2P problem...". What he wanted to
  177.  JrF> say, is a technical argument. You give me a marketing argument, which I
  178.  JrF> am not interested in now.
  179.  
  180. Not yet.
  181.  
  182.  JrF> So if something keeps us from having 16.6fps doom, it's either the cpu
  183.  JrF> (how much could a 030-50 do when using same algo like doom ?) or the
  184.  
  185. Without C2P 030-50 should be capable of max 12 FPS (that would mean it has to
  186. be 50% faster than TextDemo running without C2P, if you think that is a
  187. realistic goal), 320x240 1x1 exact DOOM engine.
  188.  
  189.  >> That's TextDemo 5.7x (unreleased version) someone tested for me.  15-20
  190.  >> FPS for a 68060/50 which is supposed to be 2-3 times as powerfull as a
  191.  >> 486DX2/50 is quite depressing, considering that that 486 will do it at 30
  192.  >> FPS.  Now just
  193.  
  194.  JrF> running DOOM... are you sure doom does as complicated mapping... 2-3
  195.  
  196. Yes, TD did no more than DOOM did (even though it may SEEM that way because of
  197. some clever lightsourcing code).
  198.  
  199.  JrF> times... IMHO in that range it depends much more on the mem interface.
  200.  JrF> cache ? Reading textures is a quite mem intensive job, especially if
  201.  JrF> you do a table lookup for reach pixel (which is hopefully in cache
  202.  JrF> sometimes).
  203.  
  204.  >> translate that to the slower Amiga's (ie, the ones only equipped with
  205.  >> 030's and 040's).
  206.  JrF> well, imho there is nothing against using the 11cycle mapper for
  207.  JrF> floor, using coppershading. at least for 020/030.
  208.  
  209. IF 020/030 THEN ... sigh...
  210.  
  211. Grtz John
  212.  
  213. -----------------------------------------------------------------------
  214.  John.Hendrikx@grafix.xs4all.nl   TextDemo/FastView/Etc... development
  215. -----------------------------------------------------------------------
  216. -- Via Xenolink 1.985B5, XenolinkUUCP 1.1
  217.